診断割り込みAPIを実行してカーネルパニックをさせてみた
いつもは守りたいカーネルをパニックさせたい。そんな時もある。
こんにちは、のんピ です。
皆さんは「このOS、カーネルパニックさせたいなぁ」と思ったことはありますか? 私はあります。
具体的には、OS構築時のクラッシュダンプ取得テスト時に「カーネルパニックさせたいなぁ」と思います。それ以外の場面では一切思いません。
従来、カーネルパニックを発生させるためには、OS内でコマンドや設定変更を行うことで発生させていました。
実はAWSのAPIを使えば、OSの外からでもカーネルパニックを発生させることができるのはご存知でしょうか。
今回はそのAWSのAPIである、診断割り込みを使ってカーネルパニックを発生させ、ついでにクラッシュダンプを分析してみようと思います。
いきなりまとめ
- 診断割り込みAPIでLinuxをカーネルパニックをさせるには事前に設定が必要
- カーネルパニックを意図的に発生させる前にはAMIなどを事前に作成して不測の事態に備える
カーネルパニックってなに??
カーネルパニックとは、OSの中核であるカーネルで致命的なエラーを検知して正常に動作しなくなる状態です。
Windowsマシンの場合はカーネルパニックが発生した時に、青い画面が表示されることから、「ブルースクリーン」と呼ばれることがあります。
動いていたマシンが正常に動作しなくなるので、基本的にはカーネルパニックが発生したら、超異常事態です。 ただ、USBメモリを挿すと30%ぐらいの確率でブルースクリーンになるマシンを見たこともあるので、マシンによっては超異常事態ではないかもしれないです。
クラッシュダンプってなに??
クラッシュダンプは、先ほど紹介したカーネルパニックなどでソフトウェアが異常終了した際に、出力するダンプファイルです。
クラッシュダンプは異常終了時のメモリの内容出力するので、「メモリダンプ」とも呼ばれます。
クラッシュダンプには異常終了時のメモリの内容が含まれているので、クラッシュダンプを分析することで、異常終了の原因を調べる助けにもなります。
診断割り込みAPIってなに??
診断割り込みAPIと呼ばれていますが、NMI(マスク不可能な割り込み: Non-maskable interrupt)を実行するAPIです。
NMIスイッチと聞けば、物理サーバーを扱ったことがあることはご存知かもしれません。
NMIスイッチを押した時の挙動としては、対象のマシンに対して、マスク不可能な割り込み(割り込み禁止にできない処理)を送信して、強制的にマシンを停止させるものです。
AWSの診断割り込みAPI実行時もイメージとしては、NMIスイッチを押された状態になります。
要するに、現在の処理に強制的に割り込んで、OSを異常終了させます。
なお、診断割り込みAPIを受け付けるEC2インスタンスは、以下、AWS公式ドキュメントの通り、インスタンスタイプの種類によります。
A1 を除き、診断割り込みはすべての Nitro ベースインスタンスタイプでサポートされます。詳細については、「Nitro System 上に構築されたインスタンス」を参照してください。
Windows Server 2019でやってみた
準備
まず、Windows Server 2019に対して、診断割り込みAPIを実行して、カーネルパニックを発生させ、クラッシュダンプを分析したいと思います。
Windowsマシンの準備は、後述するLinuxと比べて簡単です。
まず、出力するクラッシュダンプの種類を選択します。
OSログイン後、[コントロールパネル] - [システム] - [システムの詳細設定] - [システムのプロパティ] - [詳細設定] - [起動と回復] - [設定]をクリックします。
システムエラーセクションでクラッシュダンプの種類を変更します。今回は不要なページを除外した完全なメモリダンプを取得したいのでアクティブメモリダンプを選択して、OKをクリックします。
その他のクラッシュダンプの種類は、こちらのMicrosoftの公式ドキュメントをご確認ください。
Windowsマシンの場合はクラッシュダンプ作成時に、仮想メモリ(ページングファイル)を使用します。そのため、クラッシュダンプの種類と、EC2インスタンスのメモリー容量によっては仮想メモリの容量を変更する必要があります。
検証用のEC2インスタンスの仮想メモリを確認すると、以下の通り、1024MBしかありません。
しかし、検証用のEC2インスタンスの搭載メモリーが1GBで、クラッシュダンプの種類もアクティブメモリダンプであり、1024MBを丸々使うということは想定しづらいので、今回はデフォルトのままとします。
診断割り込みAPIの実行
それでは、診断割り込みAPIを実行して、カーネルパニックを発生させてみます。 AWS CLIで診断割り込みAPIの実行するコマンドは以下の通りです。
> aws ec2 send-diagnostic-interrupt --instance-id i-0b86aa6c515dcd32f >
コマンドを実行すると、ターミナル上に特にメッセージは出力されず、OSが再起動します。
クラッシュダンプの分析
診断割り込みAPI実行後、OSにログインしてクラッシュダンプを確認してみます。
デフォルトのクラッシュダンプの出力先である%SystemRoot%を確認すると、以下の通り、クラッシュダンプが出力されていることが確認できます。
それでは、出力されたクラッシュダンプの分析をしてみます。
分析をする際には、WinDbgというデバッガーを使用します。 WinDbgはこちらのMicrosoftの公式ドキュメントからダウンロードします。
ダウンロードしたWinDbgのインストーラーを実行します。
まず、インストール場所を指定します。今回はデフォルトのままとして、Nextをクリックします。
次に、使用状況と診断データの収集の設定です。送信は行わないようにしたいので、Noを選択して、Nextをクリックします。
次に、ライセンスの同意です。内容を確認して、Acceptをクリックします。
次に、インストールする機能の選択です。カーネルの分析に必要なDebugging Tools for Windowsのみにチェックを入れて、Installをクリックします。
しばらくすると、インストールが完了します。インストールが完了後にスタートを開いて、WinDbgがあることを確認します。今回は、x64マシンなのでWinDbg(X64)をクリックします。
起動すると以下のようなウィンドウが表示されます。
クラッシュダンプを分析する前に、シンボルというのデバッグに使う情報のパスを指定します。
シンボルの詳細については、こちらのMicrosoftの公式ドキュメントをご確認ください。
[File] - [Symbol file path…]をクリックして、シンボルパスを指定します。シンボルパスはsrv*C:\Windows*https://msdl.microsoft.com/download/symbolsとしました。
それでは、ダンプファイルを開いて分析していきます。
[File] - [Open Crash Dump…]をクリックして、クラッシュダンプを指定します。
クラッシュダンプを指定すると、以下のようなウィンドウが開きます。クラッシュダンプの分析を行うためには、!analyze -vをクリックします。
!analyze -vをクリックすると、分析が始まります。NMI_HARDWARE_FAILURE (80) ということから、NMIによってカーネルパニックが発生したことが分かります。
Amazon Linux 2でやってみた
準備
続いて、Amazon Linux 2に対して診断割り込みAPIを実行して、カーネルパニックを発生させ、クラッシュダンプを分析していみたいと思います。
まず、カーネルパニックの発生時にクラッシュダンプを出力するように設定をします。
クラッシュダンプを出力するサービスであるkdumpと、クラッシュダンプを解析するために、crash、kernel-debuginfoパッケージをインストールします。
kdumpはkexec-toolsというモジュールに含まれています。
実行するコマンドは以下の通りです。
$ sudo yum install -y kexec-tools crash $ sudo debuginfo-install -y kernel
実行時のログは以下の通りです。
sh-4.2$ sudo yum install -y kexec-tools crash Loaded plugins: extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 Resolving Dependencies --> Running transaction check ---> Package crash.x86_64 0:7.2.9-1.amzn2.0.1 will be installed --> Processing Dependency: libsnappy.so.1()(64bit) for package: crash-7.2.9-1.amzn2.0.1.x86_64 --> Processing Dependency: liblzo2.so.2()(64bit) for package: crash-7.2.9-1.amzn2.0.1.x86_64 ---> Package kexec-tools.x86_64 0:2.0.19-3.amzn2.0.1 will be installed --> Processing Dependency: dracut-network >= 033-522 for package: kexec-tools-2.0.19-3.amzn2.0.1.x86_64 --> Running transaction check ---> Package dracut-network.x86_64 0:033-535.amzn2.1.3 will be installed ---> Package lzo.x86_64 0:2.06-8.amzn2.0.4 will be installed ---> Package snappy.x86_64 0:1.1.0-3.amzn2.0.2 will be installed --> Finished Dependency Resolution Dependencies Resolved ========================================================================================================= Package Arch Version Repository Size ========================================================================================================= Installing: crash x86_64 7.2.9-1.amzn2.0.1 amzn2-core 2.6 M kexec-tools x86_64 2.0.19-3.amzn2.0.1 amzn2-core 348 k Installing for dependencies: dracut-network x86_64 033-535.amzn2.1.3 amzn2-core 100 k lzo x86_64 2.06-8.amzn2.0.4 amzn2-core 60 k snappy x86_64 1.1.0-3.amzn2.0.2 amzn2-core 40 k Transaction Summary ========================================================================================================= Install 2 Packages (+3 Dependent packages) Total download size: 3.1 M Installed size: 8.2 M Downloading packages: (1/5): dracut-network-033-535.amzn2.1.3.x86_64.rpm | 100 kB 00:00:00 (2/5): kexec-tools-2.0.19-3.amzn2.0.1.x86_64.rpm | 348 kB 00:00:00 (3/5): crash-7.2.9-1.amzn2.0.1.x86_64.rpm | 2.6 MB 00:00:00 (4/5): lzo-2.06-8.amzn2.0.4.x86_64.rpm | 60 kB 00:00:00 (5/5): snappy-1.1.0-3.amzn2.0.2.x86_64.rpm | 40 kB 00:00:00 --------------------------------------------------------------------------------------------------------- Total 9.3 MB/s | 3.1 MB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : snappy-1.1.0-3.amzn2.0.2.x86_64 1/5 Installing : lzo-2.06-8.amzn2.0.4.x86_64 2/5 Installing : dracut-network-033-535.amzn2.1.3.x86_64 3/5 Installing : kexec-tools-2.0.19-3.amzn2.0.1.x86_64 4/5 Installing : crash-7.2.9-1.amzn2.0.1.x86_64 5/5 Verifying : lzo-2.06-8.amzn2.0.4.x86_64 1/5 Verifying : kexec-tools-2.0.19-3.amzn2.0.1.x86_64 2/5 Verifying : dracut-network-033-535.amzn2.1.3.x86_64 3/5 Verifying : snappy-1.1.0-3.amzn2.0.2.x86_64 4/5 Verifying : crash-7.2.9-1.amzn2.0.1.x86_64 5/5 Installed: crash.x86_64 0:7.2.9-1.amzn2.0.1 kexec-tools.x86_64 0:2.0.19-3.amzn2.0.1 Dependency Installed: dracut-network.x86_64 0:033-535.amzn2.1.3 lzo.x86_64 0:2.06-8.amzn2.0.4 snappy.x86_64 0:1.1.0-3.amzn2.0.2 Complete! sh-4.2$ sh-4.2$ sudo debuginfo-install -y kernel Loaded plugins: extras_suggestions, langpacks, priorities, update-motd enabling amzn2extra-docker-debuginfo enabling amzn2-core-debuginfo amzn2-core-debuginfo | 2.6 kB 00:00:00 amzn2extra-docker-debuginfo | 2.6 kB 00:00:00 (1/2): amzn2extra-docker-debuginfo/2/x86_64/primary_db | 11 kB 00:00:00 (2/2): amzn2-core-debuginfo/2/x86_64/primary_db | 1.8 MB 00:00:00 --> Running transaction check ---> Package kernel-debuginfo.x86_64 0:4.14.232-176.381.amzn2 will be installed --> Processing Dependency: kernel-debuginfo-common-x86_64 = 4.14.232-176.381.amzn2 for package: kernel-debuginfo-4.14.232-176.381.amzn2.x86_64 ---> Package yum-plugin-auto-update-debug-info.noarch 0:1.1.31-46.amzn2.0.1 will be installed --> Running transaction check ---> Package kernel-debuginfo-common-x86_64.x86_64 0:4.14.232-176.381.amzn2 will be installed --> Finished Dependency Resolution Dependencies Resolved ========================================================================================================= Package Arch Version Repository Size ========================================================================================================= Installing: kernel-debuginfo x86_64 4.14.232-176.381.amzn2 amzn2-core-debuginfo 207 M yum-plugin-auto-update-debug-info noarch 1.1.31-46.amzn2.0.1 amzn2-core 27 k Installing for dependencies: kernel-debuginfo-common-x86_64 x86_64 4.14.232-176.381.amzn2 amzn2-core-debuginfo 31 M Transaction Summary ========================================================================================================= Install 2 Packages (+1 Dependent package) Total download size: 238 M Installed size: 974 M Downloading packages: (1/3): yum-plugin-auto-update-debug-info-1.1.31-46.amzn2.0.1.noarch.rpm | 27 kB 00:00:00 (2/3): kernel-debuginfo-common-x86_64-4.14.232-176.381.amzn2.x86_64.rpm | 31 MB 00:00:00 (3/3): kernel-debuginfo-4.14.232-176.381.amzn2.x86_64.rpm | 207 MB 00:00:07 --------------------------------------------------------------------------------------------------------- Total 33 MB/s | 238 MB 00:00:07 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : kernel-debuginfo-common-x86_64-4.14.232-176.381.amzn2.x86_64 1/3 Installing : kernel-debuginfo-4.14.232-176.381.amzn2.x86_64 2/3 Installing : yum-plugin-auto-update-debug-info-1.1.31-46.amzn2.0.1.noarch 3/3 Verifying : kernel-debuginfo-common-x86_64-4.14.232-176.381.amzn2.x86_64 1/3 Verifying : kernel-debuginfo-4.14.232-176.381.amzn2.x86_64 2/3 Verifying : yum-plugin-auto-update-debug-info-1.1.31-46.amzn2.0.1.noarch 3/3 Installed: kernel-debuginfo.x86_64 0:4.14.232-176.381.amzn2 yum-plugin-auto-update-debug-info.noarch 0:1.1.31-46.amzn2.0.1 Dependency Installed: kernel-debuginfo-common-x86_64.x86_64 0:4.14.232-176.381.amzn2 Complete! sh-4.2$
次に、セカンドカーネル（ダンプ取得用のカーネル）用に予約するメモリーを設定するために、GRUBを設定します。
Amazon Linux 2のデフォルトの/etc/default/grubは以下のようになっており、セカンドカーネル用の予約メモリーの設定項目である、crashkernelがありません。そのため、crashkernelを設定して、メモリーの予約をします。
sh-4.2$ sudo cat /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0" GRUB_TIMEOUT=0 GRUB_DISABLE_RECOVERY="true"sh-4.2$
今回は、crashkernel= 161Mにして、161MB予約します。kdumpのメモリー要件については、こちらのRed Hatの公式ドキュメントをご確認ください。
なお、crashkernel=autoとすることで、自動的に割り当てることが可能ですが、以下の通り必要なメモリーの条件があります。
一部のシステムでは、ブートローダーの設定ファイルで crashkernel=auto パラメーターを使用するか、グラフィカル設定ユーティリティーで自動割り当ての設定を有効にすると、kdump 用のメモリーを自動的に割り当てることができます。ただし、この自動予約が機能するには、合計メモリーの特定量のメモリーを利用できる必要があります。この容量はシステムのアーキテクチャーによって異なります。
例えば、AMD64 と Intel 64 (x86_64)の場合の必要メモリーは2GBですので、2GB以下のメモリーしか搭載していない場合は、crashkernel=autoとすることができません。
仮に、1GBのメモリーしか搭載していないEC2インスタンスで、crashkernel=autoとすると、kdumpサービスの起動に失敗します。
以下の通り、journalctl -xeで起動に失敗した原因を確認してみると、セカンドカーネル用のメモリーが予約されていないからだということが分かります。
(中略) -- Unit kdump.service has begun starting up. Jun 10 08:22:21 ip-10-0-1-70.ec2.internal kdumpctl[2419]: No memory reserved for crash kernel Jun 10 08:22:21 ip-10-0-1-70.ec2.internal kdumpctl[2419]: Starting kdump: [FAILED] Jun 10 08:22:21 ip-10-0-1-70.ec2.internal systemd[1]: kdump.service: main process exited, code=exited, status=1/FAILURE Jun 10 08:22:21 ip-10-0-1-70.ec2.internal systemd[1]: Failed to start Crash recovery kernel arming. -- Subject: Unit kdump.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit kdump.service has failed. -- -- The result is failed. (中略)
実際の/etc/default/grub設定変更時のログは以下の通りです。
sh-4.2$ sudo cp -a /etc/default/grub /etc/default/grub.`date +"%Y%m%d"` sh-4.2$ sh-4.2$ sudo vi /etc/default/grub sh-4.2$ sh-4.2$ sh-4.2$ diff -u /etc/default/grub.`date +"%Y%m%d"` /etc/default/grub --- /etc/default/grub.20210610 2021-06-03 20:20:56.519197651 +0000 +++ /etc/default/grub 2021-06-10 07:42:00.162460009 +0000 @@ -1,3 +1,3 @@ -GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0" +GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=161M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0" GRUB_TIMEOUT=0 -GRUB_DISABLE_RECOVERY="true" \ No newline at end of file +GRUB_DISABLE_RECOVERY="true" sh-4.2$
続いて、以下、Red Hatの公式ドキュメントの通り、/etc/default/grub の手動による変更を反映するにために、grub2-mkconfigを実行してgrub.cfg ファイルを再構築します。
/etc/default/grub ファイルは、インストールプロセスで grub.cfg を作成するときに anaconda によって使用される grub2-mkconfig ツールにより使用され、システム障害の発生時に使用できます (たとえば、ブートローダーの設定を再作成する必要がある場合)。一般的に、他の手段がない場合を除き、grub2-mkconfig を手動で実行して grub.cfg ファイルを置き換えることは推奨されません。/etc/default/grub への手動による変更を反映するには、grub.cfg ファイルを再構築する必要があります。
実行時のログは以下の通りです。
sh-4.2$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.14.232-176.381.amzn2.x86_64 Found initrd image: /boot/initramfs-4.14.232-176.381.amzn2.x86_64.img done sh-4.2$
最後に、Intel および AMD プロセッサをベースとしたインスタンスの場合は、NMI を受信した際にクラッシュするようにカーネルを設定しておく必要があります。
そのため、カーネルパラメータを設定するファイルである/etc/sysctl.confを修正します。修正内容としては、kernel.unknown_nmi_panic=1をファイルの末尾に追加します。
修正時のログは以下の通りです。
sh-4.2$ sudo cp -a /etc/sysctl.conf /etc/sysctl.conf.`date +"%Y%m%d"` sh-4.2$ sh-4.2$ sudo vi /etc/sysctl.conf sh-4.2$ sh-4.2$ diff -u /etc/sysctl.conf.`date +"%Y%m%d"` /etc/sysctl.conf --- /etc/sysctl.conf.20210610 2019-10-02 00:25:17.000000000 +0000 +++ /etc/sysctl.conf 2021-06-10 08:09:01.118690221 +0000 @@ -8,3 +8,5 @@ # name in /etc/sysctl.d/ and put new settings there. # # For more information, see sysctl.conf(5) and sysctl.d(5). + +kernel.unknown_nmi_panic=1 sh-4.2$
一通りの設定変更が完了したので、カーネルの設定変更を反映させるために一度OSを再起動をします。
sh-4.2$ sudo systemctl reboot Terminated sh-4.2$
OS再起動後、カーネルが意図した設定で起動しているのかを確認します。
確認時のログは以下の通りです。追加したcrashkernel=161Mが読み込まれているので、意図した設定で起動していそうですね。
sh-4.2$ grep crashkernel /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.14.232-176.381.amzn2.x86_64 root=UUID=f6646b81-f2a6-46ca-9f3d-c746cf015379 ro crashkernel=161M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0
最後に、kdumpサービスが起動しているかを確認します。
確認時のログは以下の通りです。自動起動が有効になっているので、正常に起動していますね。
sh-4.2$ systemctl status kdump ● kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled) Active: active (exited) since Thu 2021-06-10 08:47:27 UTC; 2min 30s ago Process: 2213 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS) Main PID: 2213 (code=exited, status=0/SUCCESS) sh-4.2$ sh-4.2$ systemctl is-enabled kdump enabled sh-4.2$
診断割り込みAPIの実行
それでは、診断割り込みAPIを実行して、カーネルパニックを発生させてみます。
実行時のコマンドは以下の通り、Windows Serverの時と同じです。
> aws ec2 send-diagnostic-interrupt --instance-id i-0a7eb4d925f14862e >
クラッシュダンプの分析
診断割り込みAPI実行後、OSにログインしてクラッシュダンプを確認してみます。
デフォルトのクラッシュダンプの出力先は、/var/crashです。/var/crash配下を確認してみると、以下の通り、クラッシュダンプが出力されていました。
sh-4.2$ ls -l /var/crash/127.0.0.1-2021-06-10-08\:55\:30/vmcore -rw------- 1 root root 28561064 Jun 10 08:55 /var/crash/127.0.0.1-2021-06-10-08:55:30/vmcore
それでは、出力されたクラッシュダンプの分析をしてみます。
分析をする際には、以下の通りcrashを使用します。
$ crash /usr/lib/debug/lib/modules/<kernel>/vmlinux \ /var/crash/<timestamp>/vmcore
実際のログは以下の通りです。PANIC: "Kernel panic - not syncing: NMI: Not continuing"の通り、NMIによってカーネルパニックが発生したことが分かります。
sh-4.2$ cd /var/crash/127.0.0.1-2021-06-10-08\:55\:30
sh-4.2$ sudo crash /usr/lib/debug/lib/modules/4.14.232-176.381.amzn2.x86_64/vmlinux /var/crash/127.0.0.1-2021-06-10-08\:55\:30/vmcore
crash 7.2.9-1.amzn2.0.1
Copyright (C) 2002-2020 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
KERNEL: /usr/lib/debug/lib/modules/4.14.232-176.381.amzn2.x86_64/vmlinux
DUMPFILE: vmcore [PARTIAL DUMP]
CPUS: 2
DATE: Thu Jun 10 08:55:24 UTC 2021
UPTIME: 00:05:51
LOAD AVERAGE: 0.00, 0.03, 0.02
TASKS: 119
NODENAME: ip-10-0-1-70.ec2.internal
RELEASE: 4.14.232-176.381.amzn2.x86_64
VERSION: #1 SMP Wed May 19 00:31:54 UTC 2021
MACHINE: x86_64 (2500 Mhz)
MEMORY: 1 GB
PANIC: "Kernel panic - not syncing: NMI: Not continuing"
PID: 0
COMMAND: "swapper/0"
TASK: ffffffff82013480 (1 of 2) [THREAD_INFO: ffffffff82013480]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash>
crashの実行後は各種コマンドを入力することで、クラッシュダンプに含まれる様々な情報を確認できます。
例えば、logコマンドを使うと、以下の通り、カーネルメッセージバッファーを表示します。
crash> log (中略) [ 506.403395] Uhhuh. NMI received for unknown reason 21 on CPU 0. [ 506.403396] Do you have a strange power saving mode enabled? [ 506.403396] Kernel panic - not syncing: NMI: Not continuing [ 506.403397] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.232-176.381.amzn2.x86_64 #1 [ 506.403397] Hardware name: Amazon EC2 t3.micro/, BIOS 1.0 10/16/2017 [ 506.403398] Call Trace: [ 506.403398] <NMI> [ 506.403398] dump_stack+0x66/0x81 [ 506.403398] panic+0xe4/0x247 [ 506.403398] ? printk+0x52/0x6e [ 506.403399] nmi_panic+0x35/0x40 [ 506.403399] unknown_nmi_error+0x6f/0x80 [ 506.403399] do_nmi+0xfb/0x150 [ 506.403399] end_repeat_nmi+0x16/0x50 [ 506.403400] RIP: 0010:native_safe_halt+0xe/0x10 [ 506.403400] RSP: 0018:ffffffff82003eb0 EFLAGS: 00000246 [ 506.403401] RAX: ffffffff8162d8f0 RBX: ffffffff821df760 RCX: 0000000000000000 [ 506.403401] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 506.403402] RBP: 0000000000000000 R08: 00000094a11d5bf3 R09: ffff88803bc31300 [ 506.403402] R10: 0000000000000000 R11: 000001431a3c3afb R12: 0000000000000000 [ 506.403402] R13: ffff88803e3f9780 R14: 0000000000000000 R15: 0000000000000000 [ 506.403403] ? __cpuidle_text_start+0x8/0x8 [ 506.403403] ? native_safe_halt+0xe/0x10 [ 506.403403] ? native_safe_halt+0xe/0x10 [ 506.403403] </NMI> [ 506.403404] default_idle+0x1a/0x100 [ 506.403404] do_idle+0x174/0x1a0 [ 506.403404] cpu_startup_entry+0x6f/0x80 [ 506.403404] start_kernel+0x4c8/0x4eb [ 506.403405] secondary_startup_64+0xa5/0xb0
psコマンドを使うと、以下の通り、プロセスの状態を表示します。
PID PPID CPU TASK ST %MEM VSZ RSS COMM
> 0 0 0 ffffffff82013480 RU 0.0 0 0 [swapper/0]
> 0 0 1 ffff88803df3c000 RU 0.0 0 0 [swapper/1]
1 0 1 ffff88803dec0000 IN 0.5 43524 5288 systemd
2 0 0 ffff88803ded4000 IN 0.0 0 0 [kthreadd]
4 2 0 ffff88803dedc000 ID 0.0 0 0 [kworker/0:0H]
5 2 0 ffff88803df00000 ID 0.0 0 0 [kworker/u4:0]
6 2 0 ffff88803df24000 ID 0.0 0 0 [mm_percpu_wq]
7 2 0 ffff88803df28000 IN 0.0 0 0 [ksoftirqd/0]
(中略)
3424 2254 1 ffff88803ac14000 IN 3.4 729228 34284 ssm-agent-worke
3425 2254 0 ffff88803ad0c000 IN 3.4 729228 34284 ssm-agent-worke
3426 2254 1 ffff88803acf8000 IN 3.4 729228 34284 ssm-agent-worke
3624 2254 1 ffff88803accc000 IN 3.4 729228 34284 ssm-agent-worke
3633 2254 0 ffff88803ad5c000 IN 3.4 729228 34284 ssm-agent-worke
3650 2254 0 ffff88803b208000 IN 3.4 729228 34284 ssm-agent-worke
3651 2254 0 ffff88803b384000 IN 3.4 729228 34284 ssm-agent-worke
3653 2254 1 ffff88803ada8000 IN 3.4 729228 34284 ssm-agent-worke
8024 3633 0 ffff888039aa8000 IN 2.5 723196 25032 ssm-session-wor
8025 2254 1 ffff88803adf8000 IN 3.4 729228 34284 ssm-agent-worke
8026 3633 1 ffff88803b24c000 IN 2.5 723196 25032 ssm-session-wor
8027 3633 1 ffff88803ad44000 IN 2.5 723196 25032 ssm-session-wor
8028 3633 0 ffff88803ac84000 IN 2.5 723196 25032 ssm-session-wor
8029 3633 0 ffff888039118000 IN 2.5 723196 25032 ssm-session-wor
8030 3633 0 ffff88803b354000 IN 2.5 723196 25032 ssm-session-wor
8035 8027 0 ffff888039a30000 IN 0.3 124188 3288 sh
8047 2254 0 ffff88803b484000 IN 3.4 729228 34284 ssm-agent-worke
8051 2 1 ffff88803ae6c000 ID 0.0 0 0 [kworker/1:0]
他にも、 仮想メモリーの情報を表示したり、オープンファイルの表示をしたりすることもできます。詳細については、こちらのRed Hatの公式ドキュメントをご確認ください。
簡単にカーネルパニックを発生させることが可能だからこそ、取扱は要注意
事前に簡単な設定をすれば、簡単にAPI経由でカーネルパニックを発生させることができることを確認しました。
最初にも記載しましたが、通常時に意図的にカーネルパニックを発生させることは非常に稀です。
APIを実行するCLIは、「本当に実行して良いですか?」といった確認もされないので、仮に実行する場合はインスタンスIDが間違っていないかなど、よく注意して実行するようにお願いします。
また、カーネルパニックがインスタンスに悪影響を及ぼす可能性もあるため、実行前にAMIなどを作成して、何かあってもリストアできるような状態にしておくことをお勧めします。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[アップデート]Amazon Connect オペレーション時間のオーバーライドがAWS CLIでサポートされたため、祝日のみ営業時間外に設定してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-a14da8621c55bd17addadcead8e0e00f/c928a36480d9593938e8d8f65ba92537/amazon-connect)
![AWS Security Hub [Config.1] カスタムロールの検出をAWS CLIで一括抑制する](https://images.ctfassets.net/ct0aopd36mqt/wp-refcat-img-cea52bc8a6ec5cad9021b38df4a08b9e/24c76ee7c1ae7aa7f9676a59c77f8702/aws-security-hub)
